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PROCEDE ORGANISATION D^UNE BASE DE DONNEES 
NUMERIOUES SOUS UNE FORME TRACABLE 

5 La pr6sente invention se rapporte au domains de 

la gestion des donnees persistantes d'une entite, par 
example une entreprise. En particulier, la pr^sente 
invention se rapporte au suivi de ces donnees persistantes 
dans une base de donnees par 1 ' intermSdiaire d'un Systeme 
10 de Gestion de Base de Donnees. II est en effet difficile 
pour une entreprise de garantir le suivi du processus 
d' Evolution des donnees persistantes stratSgiques car ce 
suivi presente guelques obstacles objectifs : 

• Caract&re asynchrone et collaboratif du 
15 d6roulement du processus 

• Car.actere trds exigeant du suivi pour constituer 
une rgelle garantie : la presence d'un maillon faible 
compromet d4f initivement la f lability de toute rgponse 

• Non disponibilite de solutions g^neriques de 
20 prise en charge de la tragabilit^ dans les couches 

logicielles du march^ & un niveau de granulariisg . 
satisfaisant : OS, SGBD, langage de d^veloppement 

• Cout tr^s #lev6 de r#criture des applications 
existantes et cofit tr%s 61ev6 de prise en compte explicite 

25 de la tragabilitg par chaque application. 

L'art ant^rieur connalt d^ja par la demande de 
brevet international wo 9935566 un proc^d^ d ' identification 
et de suivi des Evolutions d'un ensemble de composants 
logiciels. Le p.roc6d# propose par ce document de I'art 

30 antSrieur peimet de recenser des composants par leur nom et 
leur version. Cette classification au niveau fichier ne 
correspond pas au problSme de conserver des traces de 
donnges de manifere continue, c ' est-a-dire a chaque 
modification desdites donnees. En particulier, le procedE 




propose ne convient pas pour tracer une base de donnees 
modifiee a chaque acces en ecriture. 

II est propose, dans le brevet amSricain US 
5 5,347,653 une mSthode fournissant une perspective 
historique ci une base de donnees d'objets grace a un 
versionnement des objets stock€s ainsi qu'Si une indexation 
representative des objets. Cette m^thode de I'art anterieur 
propose de stocker intSgralement la derniere version de la 

10 base de donnSes et de stocker d' autre part les differences 
& appliquer a cette derniere version pour obtenir des 
versions antSrieures. Le probl^me posS par ce docxament est 
la necessity d' appliquer les differences une k une et en 
serie pour trouver I'etat de la base h. une date donn^e. 

15 Cette contrainte implique un cout en temps important* 

La presente invention entend remSdier aux 
inconvenients de I'art anterieur en proposant un procede de 
suivi de 1' evolution des donnees dans une architecture 
basee sur un S6BD, consistant en : 

20 ® la materialisation des versions intermediaires et 

des flux de donnees resultantes des operations effectuees 
sur la base de donnees, au fur et & mesure de son 
evolution, au niveau de granularite eiementaire 
( enregistrement par enregistrement et attribut par 

25 attribut) ; 

^ la possibilite de reconstitution et restitution 
« rapide » de tout etat cadre historique d'origine de 
chaque version de donnee et chaque operation (par 
« rapide » nous comprenons « sans temps additionnel 

30 perceptible lie a la restaur at ion » ) ; 



comprenant 
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• des m^canismes de reconstitution de flux de 
dSpendance causale (de type source-destination) entre les 
donnSes concernees ; 

des m^canismes de notification de remise en cause 
5 des operations du pass^ en cas d' Evolution des donn^es 
d' entree ; 

• des mecanismes de r6-ex6cution ; 

et couvrant les cas particuliers et les extensions 
10 suivants : 
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prise en compte de 1' Evolution structurelle 
(Evolution de sch^a) ; 

prise en compte de 1' Evolution des applications ; , 
prise en compte des applications existantes dans 
un cadre architectural flexible ; 

sch#mas d' Evolution graduelle d'une architecture 
h. 1' Schelle.de I'entreprise ; 

• gestion de versions virtuelles (families 
20 alternatives et hypotheses parall^les). 

Le but principal de 1' invention est de • 
permettre 1 ' exploitation des donnSes de la base selon des 
versions successives, tout en limitant les besoins de temps 
et capacity de stockage et h autoriser la restitution h la 
25 volSe. 

Une demarche habituelle consiste a enregistrer 
des versions successives des bases de donn€es, par exemple 
sous la forme de stockage pSriodique sur un support telle 
qu'une cartouche magnStique de 1 ' integrality de la base de 
donnees, dans l'#tat correspondant a la version courante. 
La recherche d'une information n^cessite la restauration 
prealable de toute la base, a partir du support 
correspondant h. la sauvegarde correspondante, puis k 
interroger la base ainsi restaurSe. Pour des bases de 
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donnges importantes telles qu'exploitees dans le domaine 
bancaire, de 1' assurance ou de la gestion, le volume 
correspondant k un €tat peut d^passer le teraoctet, volume 
qu'il convient de multiplier par le nombre d'etats 
sauve gardes . 

Cette solution est totalement inadapt#e a 
1' exploitation en temps r^el. 

L' invention vise k rgpondre au probleme 
technique de 1 ' exploitation en temps r6el de bases de 
donnees de grande volume. 

A cet effet, 1' invention concerne dans son 
acception la plus gen^rale un procSde d' organisation d'une 
base de donnees num^rique sous une forme tragable, 
comportant des Stapes de modification d'une base de donnees 
num^riques principals par ajout ou suppression ou 
modification d'un enregistrement de la base principale et 
des etapes de lecture de la base de donnees principale, 

caractgris6 en ce que 

I'^tape de modification de la base de donnees 
principale comprend une operation de creation d'au moins un 
enregistrement numSrique comportant au moins : 

les identifiants num^riques uniques des 
enregistrements et des attributs concernSs de la base de 
donnees principale, 

un identifiant num^rique de I'etat de la base 
de donnees principale correspondant a ladite modification 
de la base de donnees principale, 

les valeurs ^lementaires des attributs qui leur 
sont affectSes a travers les operations 616mentaires , sans 
proc^der au stockage des attributs ou des enregistrements 
non modifies, 

et d' ajout dudit enregistrement dans une base 
d'historisation interne compos6e d'au moins une table 
d'historisation interne. 
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et en ce que I'Stape de lecture portant sur 
tout 6tat final ou antSrieur de la base de donnees 
principale consiste a effectuer une requite originelle 
associ^e & 1 ' identif icateur unique de I'etat vise, ^ 
proceder h une transformation de ladite requete originelle 
pour construire une requ§te modifi^e d'adressage de la base 
d'historisation comprenant les criteres de la requete 
originelle et 1 ' identif icateur de I'^tat vis^, et de 
reconstruction du ou des enregistrements correspondant aux 
critferes de la requete originelle et a I'etat vis6, ladite 
6tape de reconstitution consistant h retrouver les valeurs 
gl^mentaires , contenues dans les enregistrements de la base 
d'historisation, correspondant aux critSres de la requite 
originelle [afin de reduire les besoins de capacity de 
stockage et les temps de traitement], 

Selon une variante, lesdits enregistrements de 
la base de donnees d'historisation contiennent 6galement 
des references ^ d'autres enregistrements de la base de 
donnees interne, dans le but de pr^ciser les liens de 
d^pendance dynamique de type source-destination constituant 
le flux causal des interferences entre les versions des 
donnSes . 

Avantageusement, ladite operation de 
modification de la base principale est une operation 
logique et ladite operation d' a jout dans la base de donnees 
d'historisation consiste ^ ajouter : 

un enregistrement identif iant I'^tat de la base 
correspondant & 1' operation logique, 

autant d' enregistrements que de param^tres de 
1' operation logique, 

un enregistrement pour le r^sultat eventuel de 
1' operation logique 

et a preciser par un lien de parente les 
regroupements d' operations depuis le niveau elementaire de 
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modification jusqu'au niveau de la transaction, en passant 
le nombre de niveaux s4mantiques n^cessaires pour les 
applications . 

Selon une autre variante, la base de donates 
principals contient une ou plusieurs table(s), organisant 
les liens d' Evolution entre les identifiants des ^tats 
successifs et alternatifs de la base principale, 
destin6e(s) a organiser les enregistrements de la base de 
donates interne. 

De pr^fdrence, ladite ou lesdites tables des 
liens d' Evolution entre les 6tats de la base principale 
contiennent des enregistrements sp^cifiant les regies de 
correspondance entre les enregistrements de la base de 
donnees interne d'historisation et les 6tats de la base de 
donnees principale. 

Selon un mode de mise en oeuvre particulier, 
ladite operation de lecture consiste h. determiner ledit 
6tat de la base de donnees principale en se r6f#rant aux 
dits identifiants et aux tables des liens d' Evolution entre 
les etats de la base principale. 

Avantageusement, une application interrogeant 
la base de donnfies principale peut specifier I'etat de la 
base de donnees principale d^sir^. 

L' invention concerne ggalement une architecture 
de gestion de base de donnees caract6ris4e en ce que ladite 
application peut opgrer des modifications sur tout etat de 
la base principale et donnant lieu, dans le cas de la 
tentative de modification d'un 6tat ant^rieur, a la 
creation de nouvelles alternatives d' Evolution de la base 
de donnees principale dont les donnees seront gen^r^es par 
la m&ne base d'historisation interne. 

Selon une variante, les liens de dependances 
servent de criteres de remise en cause desdites operations 
d&jk effectuees. 



De pr^f^rence, les raises a jour effectuees sur 
des branches differentes pourront §tre int^grees ou 
fusionn^es dans le cadre d'un nouvel etat « h^ritant » 
desdites branches. 

Selon iin mode de mise en oeuvre particulier, les 
cas d' Evolution de structure des donn^es de la base de 
donn^es principale sont traites comme des cas particuliers 
d' Evolution des donn^es de ladite base, pour peu que la 
structure/schema de ladite base principale soit d^crite de 
la fagon mentionn^e pour les donn^es, en tant que 
dictionnaire . 

Selon une autre variante, la base de donn^es 
d'historisation est explorSe et interrog^e par des.. 
applications ^ travers le mode natif du SGBD afin d'obtenir 
des informations comme par exemple toutes les valeurs 
historigues d'un attribut et toutes les incidences, 
(dynamiques) de toute mise h jour et de naviguer au long 
des versions et des flux de d^pendance dynamique et ceci de . 
fagon classique, selon le langage d' interrogation en.' 
vigueur, exigg par le SGBD. 

On comprendra mieux la presente invention a 
I'aide de la description, faite ci-aprSs a titre purement 
explicatif, d'un mode de realisation de 1' invention, en 
reference aux figures annex^es : 

La figure 1 illustre une architecture classique 
de communication entre une application et une base de 
donnSes ; 

La figure 2 illustre une architecture de 
communication similaire & celle de la figure 1 et 
comprenant les Elements n^cessaires a 1' application de 
1 ' invention ; 
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La figure 3 illustre les differents moyens 
d'acc^s a une base de donn^es organis^e de fa9on tragable 
munle d'un systeme selon 1' invention. 



La gestion des donnees persistantes d'une 
entreprise (ou d'une organisation au sens large) est 
generalement confine a un logiciel sp^cifique appelS aussi 
SGBD. Les applications inf ormatiques proposent aux 
utilisateurs des moyens ergonomigues interactifs capables 
de visualiser et faire ^voluer les donnees de la base de 
donnees de 1' entreprise en coininuniquant avec le SGBD. Dans 
les paragraphes suivants, nous rappelons les principales 
caract6ristiques de 1 'architecture afin de positionner le 
cadre de notre proc#d6 de suivi de 1' Evolution des donndes 
et d'en fixer le vocabulaire minimal. 

Le gestionnaire de persistance nScessaire pour 
notre systfeme autorise le stockage des donnges et leur 
reconstitution en m&aoire en conformity avec leur structure 
(d^finie comme un ensemble d'attributs) et les valeurs 
saisies ou calcul^es. Les principaux SGBD Relationnels 
(mais aussi bien de type objet, rSseau ou higrarchiques ) du 
march6 sont des bons candidats pour le r61e de gestionnaire 
de persistance. Cette compatibility est d'ailleurs un atout 
de notre procSd^ qui peut aussi tirer ainsi profit de la 
base logicielle instance dans 1' entreprise. 

Consid^rons par simplification - et uniquement 
a titre d'exemple - 1' utilisation d'un SGBD Relationnel. 
Celui-ci permet la representation des donnees sous forme de 
tables (ou relations). Les colonnes indiquent les attributs 
(ou champs). Chaque colonne est caractirisge par un domaine 
(entier, caractfere, date, flottant, etc.) et d'autres 
informations 6ventuelles comme la taille maximale (pour les 
chaines de caract&res). Certains attributs (un ou 
plusieurs) constituent la clS ou 1 ' identif iant de 



I'enregistrement. Dans la figure suivante^ nous avons 
represents une table et nous avons indiqu6 les cles en mode 
souligne. Chaque ligne d'une meme table reprSsente un 
nouvel enregistrement (ou n-uplet) de structure uni forme. 
Chaque cellule represente la valeur de 1' attribute Par 
exemple^ « aaa » est la valeur de I'attribut Attributl du 
premier enregistrement dont la cle est 1001. 



Table 



CIS 


Attributl 


Attribut2 


1001 


« aaa » 


23/12/2001 


1002 


« bbb » 


24/11/2000 


1003 


« ccc » 


8/05/1989 



Les donnSes sont ins6r#es, lues, modifiSes et 
supprim^es ^ travers un langage de manipulation de donn^es 
( SQL par exemple ) . 

Le gestionnaire de persistance permet ggalement' 
la definition, la consultation et 1 'Evolution de la 
structure des donn^es, appel6e aussi schema de donn^es. 
Ainsi, les tables peuvent gtre dgfinies, supprim^es ou 
restructur#es. Dans le dernier cas, des colonnes peuvent 
§tre rajoutges ou supprim^es. Parfois, il est utile mSme de 
changer le domaine d'un attribut, ou d'autres 
caract^ristiques analogues, ce qui peut impliquer des 
traitements implicites ou explicites de conversion des 
donn^es concem€es . 



Quelle que soit la representation physique des 
donn^es, la table est la reference logique de 
representation des donn^es . Ainsi, les applications 
« voient » g^neralement les donnges sous la forme de 
tables. II est important de souligner que notre systeme 
tient a preserver cette representation logique afin de 
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10 

s' assurer la plus grande compatibility avec les 
applications existantes. Par exemple, aprds avoir demande 
la connexion & une base de donnees particuliSre, une 
application peut s'adresser a un gestionnaire de 
persistance avec une requite de type "select * from client" 
et recevoir en 6change un ensemble de donates permettant la 
reconstitution des donnees sous forme tabulaire. 

Pr^cisons enfin qu'une base de donnees 
repr^sente un 6tat coherent du monde reel represents. Les 
donnees de la base Svoluent par a-coups declenchSs par des 
6v6nements & travers des operations (insertion, mise ^ jour 
ou suppression) regroupges gfinSralement en transactions. 
Ces dernidres sont caract6ris6es par des propriStSs 
particuliferes dites ACID (Atomicity, Coherence, Isolation 
et Durability) qui garantissent un certain niveau de 
quality. 



20 



25 



L'objectif poursuivi par 1' invention est de 
fournir aux applications inf ormatigues et k leurs 
utilisateurs la capacity de suivre de fagon precise les 
donnees tout au long de leur yvolution, en tragant leurs 
histoires de fagon compl&te, aussi bien sur le plan 
individuel (versions intermydiaires et liens de succession) 
que sur le plan collectif (ev^nements declencheurs et liens 
d'interdependance dynamiques issus des interactions entre 
les versions donnyes), en la positionnant dans le cadre 
cohyrent de son deroulement originel. 

s'agit done de fournir des liens de 
causalite k un niveau eiementaire ou I'on puisse suivre 
aisement le flux causal des transformations et verifier la 
validity de chaque operation intermediaire sous la base des 
donnees d' entree, du traitement applique et des donnees 
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rSsultantes, de telle fagon que la reconstitution de tout 
6tat du pass6 soit immediate. 

De plus, le proc4d6 selon 1' invention utilise 
un cadre architectural flexible, aussi peu contraignant et 
intrusif que possible afin de fournir une trds large 
applicability au proc6d6 propose et une aussi large 
compatibilite que possible avec les proc#d6s de stockage et 
manipulation des donn^es courantes. 

Afin d' assurer le suivi de 1 'Evolution d'une 
base de donnges dite « principale >. , le proc^dS selon 
1' invention permet de faire en sorte qu'elle represents rion 
pas seulement un mais tous les 6tats cohSrents successif s . 
et/ou alternatifs n^cessaires du monde r6el represents dans 
son evolution, tout en prSservant les propriStSs ACID. 



Dans ce but, 1 ' architecture inise en oeuvre pour 
1' invention est illustrSe figure 2 et est constitute comme 
20 suit : 

un journal (J) organist sous la forme d'une 
« base de donnSes interne d'historisation » constitut d'une 
table ou d'un ensemble de tables dtdites au suivi de 
1' evolution et bastes sur un mode de stockage universel a 
schema stable (indtpendant de la representation logique des 
donnees applicatives ) et particuliSrement adapte a la 
reconstitution & la volee des donnees. 

un moniteur de transactions (M) et d'tvenements 
capable de detecter toute demande d' evolution de valeurs et 
de structure transmise & la base de donntes qui rajoute au 
fur et h mesure dans le journal dedie des entrees 
caracterisant 1' evolution eiementaire des donnees 
(identite, attribut, valeur, evtnement dtclencheur et 
dependances dynamiques) 
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un module de reconstitution (R) a la vol^e de 
I'etat de la base de donnees selon un evenement cible ; le 
systeme est muni dans ce but d'un curseur (C) dedie a la 
selection de I'^tat recherche. 
5 cas particulier : dans certains cas, il peut 

s'av^rer utile de materialiser la vue de la base dite 
« courante » ou « principale » sous la forme des tables de 
structure sp6cialis6e, par exemple pour permettre des 
performances Slevees et une compatibility totale avec des 
10 applications existantes (notamment afin de permettre 
1' usage des procedures stockSes et autres declencheurs ou 
triggers qu'une application peut exiger pour fonctionner 
correctement ) . 



15 Optionnellement , 1 ' architecture comprend 

6galement : 

un systeme de suivi de la conformity (SC) des 
applications avec les 6tats de la base et de son schema 

des outils d' inoculation (I) automatique dans les 
20 applications d ' instructions dSdiSes au suivi des 
dependances dynamiques (capture des flux de donnSes) 

Le journal (J) d'6venements (ou la base de 

donnees interne d ' his torisation ) est constitu6 
25 principalement d'une table a structure ind^pendante de 

celle des donnSes applicatives . Les colonnes sont : 

® un identifiant unique de 1 'enregistrement de la 

table logique concern^ par la ligne de journal, appar tenant 

§L la cle principale 
30 « un identifiant de I'attribut dans le schema, ou 0 

pour I'enregistrement lui-meme, appartenant a la cle 

principale 



• un identifiant xiniversel d ' e v^nement. , incremente 
automatiquement , appartenant egalement a la cle principale 
du journal et correspondant h I'dtat de la base principale 

• un champ valeur dedie au stockage des valeurs 

Le role du moniteur (M) est de detecter et 
d' interpreter correctement chaque demande d' evolution en 
rajoutant 1 ' information correspondante dans le journal 
d ' evenements ( J ) . 



Examples d' Evolution de valeur 





ID 


Attribut 


UBID 


Valeur 


- insertion 










110 


0 


52 


53 


d ' enregistrement 










- laise a jour 


110 


1 


853 


1001 


d'un attribut. 










-• raise h jour 


110 


2 


854 


"aaa" 


d'un attribut 











- suppression 


110 


0 


981 


0 


d'un 










enregi s trement 











Commentaire 

ID table 
« client » 
No du client 

Norn du 
client 

Code 
suppression 



Dans le langage d'^change avec une base de 
donn^es SQL, les trois premieres lignes du tableau peuvent 
§tre I'effet de la requ§te suivante : 

insert into Client (no_client, nom_client) 
values (1001, "aaa") 

Une telle requete est traitee comme suit : 
• analyse syntaxique (parsing) de la requete 

recuperation depuis le schema des identifiants 
pour la table client (53) ainsi que pour les attributs 
« no_client » (1) et « nom_client » (2) 




10 



14 

insertion des trois lignes dans le journal 

La derniere ligne pent etre obtenue par 
1 ' instruction suivante : 

delete from Client where No_client=1001 
Une telle requete est traitee coinme suit : 
analyse syntaxique (parsing) de la requete 

* recuperation depuis le schema des identifiants 
pour la table client (53) ainsi que pour I'attribut 
« no__client » (1). 

* recuperation de 1 ' identif iant de I'enregistrement 
du journal ayant la valeur 1001 pour I'attribut no 1 

® insertion dans le journal de la derniere ligne 
(en utilisant le code 0 pour la valeur). 



15 



Exemples d' Evolution de schema 

create table Client (no_client int primary key) 



Creation d'une 
nouvelle table 



Ajout d'un 
attribut 



ID 




UEID 


Valeur 






53 


0 


252 


8 


53 


1 


253 


« Clien 
t » 


54 


0 


254 


9 


54 


1 


255 


« no_cl 
lent » 


54 


2 


256 


Int 


54 


3 


257 


PK 


54 


4 


258 


53 



Commentaire 

ID table 
des tables 
Nom de la 

table 
ID table 

des 
attribut s 

Nom de 
1 ' attribut 
Domaine 

Cle 
primaire 
ID table 




10 



15 
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alter table Client drop column no_client 

Code 
suppression 



Suppression 
d'un attribut 


54 


0 


278 


0 


Suppression 
d'une table 


drop 


table 


Client 




53 


0 


293 


0 


Autre s cas : 
dSplacement 
d' attribut 




54 


3 


308 


22 



Code 
suppression 

Mise k jour 
ID table 



20 



complexe, sans Equivalence en une seule operation SQL. IJn 
outil de gestion interactive peut en revanche pennettre de 
tirer un r6el benefice de cette caract^ristigue. 

Comme on peut le remarquer, chaque #v6neinent 
qui tend & modifier la base de donn^es logique finit par 
cr^er une ou plusieurs entries sous la forme de nouvelles 
lignes (ou enregistrements ) dans le journal. Ceci garantit 
que rien ne se perd et que toute suppression ou mise a jour 
logique ne se traduit pas en une suppression physique. 
Ainsi, les donnges du pass# peuvent etre recup#r6es. Un des 
avantages de cette organisation est la constitution 
concurrente de vues comme les livres de comptes qui 
bloquent g6n6ralement I'acces en mise a jour d'autres 
utilisateurs . 



25 



Remarguons Egalement 1' uniformity de la 
structure de stockage des informations : les donnees sont 
stock^es en effet de fagon identigue, qu'il s'agisse de 
1' evolution des valeurs ou de celle des structures. Ceci 
veut dire que du point de vue logique, il est possible de 
reconstituer aussi bien les tables logiques que leurs 




Structures, sur la base d'un meme m^canisme. Par ailleurs, 
le fait d'inclure le journal dans la in§me base de donnges 
que la base principale permet de garantir sa coherence 
relative de par le mecanisme transactionnel assurg par le 
SGBD. 

Le module de reconstitution (R) a en charge 
justement la restitution en format logique des donn^es en 
fonction d'un paramStre de type 6venement, H partir du 
j ournal d ' 6v6nements ( J ) , 

Par exemple, consid^rons que 1 ' application 
souhaite obtenir les donn^es de la table Client telle 
qu'elle 6tait juste lors de l'6v#nement 854. Cela implique 
au prgalable la selection de l'6v6nement 854 par le curseur 
d'6v6nements (C). Par la suite, la requgte "select * from 
Client" est transmise au SGBD mais transformSe par le 
module (R) en une requSte plus complexe, obtenue de la 
fagon suivante : 

° reconstitution du schema correspondant : la 
requdte porte sur la table Client ; le systSme doit done 
verifier 1' existence de la table Client au moment 
historique positionng par l'6v6nement cible et r^cup^rer 
les attributs de cette table logique ; (une optimisation 
est possible en gardant le schema en cache) 

recuperation des enregistrements dont le champ 
Attribut = 0 crees et non supprimSs « avant » I'^venement 
correspondant a I'^tat cible, (valeur = 0 pour le code de 
suppression) et attaches a cette table. Dans le cas des 
alternatives, « avant » ne concerne que les ^v^nements 
situSs sur la meme branche. 

» recuperation de tous les enregistrements dont le 
champ Attribut <> 0 attaches aux precedents et anterieurs a 
I'evenement cible. 




17 

• reorganisation du flux de donnges restitutes et 
regroupement par enregistrement logique, c ' est-d.-dire dans 
notre cas, par client. 



10 



15 



Dans un mode de realisation de 1' invention, il 
est possible de faire des requetes de modification sur des 
etats passes de la base de donnees principale de fagon ^ 
creer une arborescence des versions de la base de donnees 
traitee. 



En plus des valeurs et des evenements, le 
journal peut accueillir les invocations d ' operations . Cela 
peut etre realise par la representation des operations sous 
la forme de tables logiques, ou chaque operation correspond, 
a uri nom de table logique et chaque argument correspond h 
un attribut logique. En appliquant ce schema de 
correspondance, 1 ' application peut envoyer au journal (par 
exemple, par 1 ' intermediaire d' une API : « Application 
Programming Interface », interface de programmation 
20 d' applications) les informations " necessaires h la 
tragabilite des appels d' operation de fagon analogue h la 
manipulation des donnees logiques (mais cette tache peut 
etre automatisee et confiee a un post-processeur, au 
compilateur, au processeur ou encore a la machine 
25 virtue lie). 

add (2, 8) 
Invocation de 



1' operation Add 

avec les 
arguments 2 et 8 

57 est 
1 ' identif icateur 
de 1' operation 
« add » 



ID 


Attribut 


UBID 


Valeur 






62 


0 


401 


57 



Commen-baire 



ID operation 
« Add » 
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62 est 
1 ' identif icateur 
de cette 
invocation de 
1' operation 
« add » 



62 


1 


402 


2 


Premier 










argximent 


62 


2 


403 


8 


Second argument. 


62 


999 


404 


10 


Valeur de 










retour 



lies appels d' operation permettent de raccorder 
la s^mantique des actions de 1' application aux gvenements 
enregistr^s dans le journal • Conrnie nous le verrons plus 
5 tard, cela facilitera le positionnement du curseur sur des 
reperes signif icatif s du point de vue de I'utilisateur . 

De surcrolt, les points de validation des 
transactions peuvent etre traces sous la forme 
d' operations. En effet, il est recoiratiand^ que le curseur se 
10 posit ionne exactement sur ces points et non pas entre deux 
operations d'une m%me transaction. La coherence du rfisultat 
en depend. En revanche, des applications comme les outils 
d'aide h la conception peuvent tres bien b6nef icier des 
Stats intermSdiaires , r#put6s incoherents, dans un but 
15 explicatif, et benSf icier ainsi de mecanismes de type 
« transactions longues » . 

Prgcisons enfin que les operations sont relives 
par des references (non-reprSsentees dans les tableaux) 
vers les operations parentes de telle sorte que I'on puisse 
20 tracer egalement leur appartenance a 1' execution d'une 
operation de plus haut niveau. Ainsi, il sera possible de 
. reconstituer 1 ' appartenance des operations, depuis le 
niveau elementaire des evenements et jusqu'au niveau des 



trcLnsactions , en passant par autant de niveaux d' invocation 
que necessaire pour les applications. 

Ii'invention concerne egalement la 
5 materialisation des liens de causalite* 

Le flux des d§pendances causales doit etre 
constitue dynamiguement par les operations de lecture et 
mise a jour en respectant les regies suivantes : 

10 La manipulation des donnees doit 

systematiquement considerer aux cotes des donnSes lues 
leurs references d'origine et les transporter tout au long 
du flux de donnees et controle, L ' application doit done 
prendre en charge cet aspect^ en ajoutant a chaque 

15 instruction de manipulation son Equivalent de transport de 
references, par exemple par 1 ' intermedial re d'une API. 
L ' automat isat ion de cette tache peut etre realisee par un 
post-processeur et/ou par des extensions du processeur ou 
de la machine virtuelle. 

20 

Lors de 1' insertion d'une donnee physique, les 
references du flux I'ayant alimentee doivent etre stockees^ 
sous la forme d'une liste d' elements de type ID-attribut- 
UEID, aux cdtes de I'attribut v&leur, et ceci pour chaque 
25 enregistrement physique du journal. Le tableau suivant en 
fait 1' illustration. Une liste vide correspondrait & 
1' introduction d'une valeur de I'exterieur du systeme (par 
exemple, par la saisie effectuee par un utilisateur a 
travers une Interf ace-Homme--Machine) . 

30 



10 



15 



20 




ID 


A-bt.ribu-b 


UE 
ID 


Valeur 


Sources 


110 


2 


54 
3 


"aaa" 




110 


3 


54 
4 


2 


••• 












110 


4 


75 
3 


"aaa2" 


ID 


Attribute 


UEID 


11 
0 


2 


543 


11 

0 


3 


544 













Commen-baire 



Iia valeur de 
I'attribut 4 a 
6t,6 constitute 

a partir des 
attributs 2 et 
3 



L' implementation des sources dans le journal 
peut tres bien etre r6alis6e par 1 ' intermediaire d'un 
journal additionnel (ou sous- table), organist de fagon 
tabulaire, et ceci pour des raisons d 'optimisation de 
performances, selon les techniques en vigueur dans la 
discipline des bases de donntes. 

L' interpretation du flux se fait de manidre 
simple : la valeur d'une donnte depend des valeurs des 
donnees sources lues aux moments rtftrencts par les 
tvSnements UEID correspondants^ On peut done dire que les 
sources mattrialisent les liens de causalitt tlementaires . 

L' invocation des operations peut etre tracSe de 
la meme maniere. Voici ^ titre d'exemple, I'appel de 
1' operation Add (mentionn6e prectdemment ) avec les 
arguments Client. Attr3 et la constante ?• 



20 



10 
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ID 


Atliribut 


UBID 


Valeur 


Sources 


62 


0 


401 


57 




62 


1 

* 


402 


2 


ID 


Attribut 


UEID 


11 
0 


3 


543 


62 


2 


403 


7 




62 


999 


404 


10 





Commen-taxre 

ID operation 
« add )> 
Premier 
argument. 

Second 
argumen-t 
Valeur de 

retour 



Le controle de validite des operations peut 
etre effectue par rapport aux donn^es en vigueur* Par 
exemple, si la valeur de 1' attribut Attr3 du Client 110 
change apres 1' execution de 1' operation « add », les 
resultats envoyes par celle-ci ne peuvent plus etre 
consideres comme conformes. On dit qu'il y a « remise en 
cause » . Dans le cas d'une Evolution sans alternatives 
cela peut etre verifi6 grace a une simple comparaison 
d'UEID entre les sources des arguments et les dernieres 
valeurs des sources r6ferenc6es. 



15 



20 



Pour que cette information de tragabilitg soit 
entierement efficace pour I'utilisateur, il est utile de 
minimiser les constcintes^ c'est-a-dire les valeurs saisies 
« arbitrairement ». L' application doit ainsi privilggier 
des systemes d' identification par liste de choix, par 
pointage, par glisser-d^placer , etc., ou par toute autre 
technique qui am^liore a la fois I'ergonomie de 
1 ' application et qui permet dLmplicitement 1' assurance d'un 
suivi sans discontinuity du flux de fabrication. En 
reality IT ces techniques sont largement rSpandues car elles 
assurent des avantages de rgf Srencement statique prgvu dans 
les bases de donn^es de fagon courante. 



25 




Cette technique permet de surcroit la mise en 
place d'un systeme d' optimisation automatique , qui — sur la 
base de la verification systematique de la validity des 
sources — permet de renvoyer le r^sultat calculg 
5 pr^c^demment, sans r6ex§cuter ef f ectivement 1' operation • La 
mise en place d'une telle solution implique 1' introduction 
des references vers les operations appelantes (ce qui peut 
etre fait a travers des arguments supplementaires ) et h 
condition que le temps de verification soit inferieur a 
10 celui d' execution (des statistiques de performances peuvent 
etre maintenues k titre informatif et exploitees 
ef f icacement) . 

La notification automatique des « remises en 
cause » pourra etre mise en place sur la base des 
informations de validite des versions des donnees par 
rapport aux flux. Ainsi, pour une operation, une classe 
d' operation, une cible ou une source donnee, des alerteurs 
de coherence de flux pourront notif ier les applications par 
des messages synchrones ou asynchrones. 

La re-execution consiste en une nouvelle 
invocation explicite d'une operation donnee sur le moddle 
d'une invocation precedente, mais sur la base de nouvelles 
25 valeurs. Dans tous les cas, elle donnera lieu h des 
nouvelles valeurs pour les donnees, les operations et les 
sources tracees. 

Le precede selon 1' invention est specialement 
30 congu pour gerer de fagon operationnelle 1 'historisation au 
fil de I'eau et la restauration a la volee. De plus, la 
gestion des volumes de stockage est facilitee et optimisee 
par un ensemble de facteurs : 



15 



20 




• seules les valeurs attributs qui changent sont 
s-tock^es (la redondance est ainsi minimisee) 

• les volumes necessaires de stockage 
supplement aires augmentent de fagon lin^aire avec le nombre 

5 des attributs modifies ou supprimes et ne dependent pas des 
volumes de donnees ins^r^s dans la base ; ce facteur 
autorise une utilisation tres avantageuse pour un tres 
large spectre d' applications de gestion. 

• enfin, les purges tres pertinentes peuvent etre 
10 oper^es selon les donnees marquees comme remises en cause 

par les liens de tragabilite de type source-destination, 
mais cette operation doit etre pilot^e par les applications 
en fonction de la s6mantique des remises en cause. 

15 Pour des raisons de simplification du discourse » 

dans I'exemple pr6c(§dent, nous avons fait I'hypothese. 
implicite d'une organisation s#quentielle des 6v6nements et;. 
done des ^tats de la base principale (selon un ordre^ 
total). Ainsi, pour verifier la validite d'une source, nousi 

20 avons 6voque coirane solution la comparaison simple desi 
identifiants universels d'6v6nement (UEID). 

En r6alit6, notre procSdS autorise un vaste 
choix d' organisation des versions, comme par^exemple : 

• Arborescence : chague 6v6nement a un 6v6nement 
25 parent. La valeur d'une donn^e associ^e a un 6vSnement peut 

etre obtenue par une remont^e logique des peirents jusqu'a 
la valeur la plus proche. 

• Graphe orients sans circuit : analogue a 
1' arborescence, cette organisation permet a une version 

30 d' avoir plusieurs parents diff brents. Les ambiguitSs de 
resolution peuvent etre levees par des regies pred6finies, 
basees sur des criteres de priorite des branches ou sur 
tout autre caracteristique de la donnee { son type , etc . ) 




Les evolutions des branches diffSrentes peuvent 
etre fusionn^es en faisant appel a la r6-execution des 
operations. 

Les versions virtuelles sont des branches 
d'evenements predefinies qui permettent la constitution de 
configurations paralleles pouvant bgngficier simultangment 
des gvenements appliques H une ou plusieurs branches dites 
« de rgfgrence ». Autres caract^ristiques : 

Les gventuels conflits sont ^vit6s par la 
separation des ev^nements par nature en branches de 
reference selon le module 6voqu6 dans 1' organisation de 
graphe orients sans circuit. 

* La materialisation de ces configurations n'est 
pas reelle car les Svenements ne sont pas dupliquSs 
physiquement ( la propagation est logique ) . 

L' architecture mise en oeuvre pour la 
realisation de 1' invention peut aussi comporter les modules 
suivants 



"» un systgme de suivi de la conformity (SC) des 
applications avec les etats de la base et de son schema. Le 
principe est base sur 1 ' enregistrement d'un identifiant de 
version de 1 'application afin de declarer un niveau de 
compatibilite avec le ou les etats correspondants au schema 
de la base principale 

des outils d' inoculation (l) automatique dans les 
applications d ' instructions dediees au suivi des 
dependances dynamiques (capture des flux de donnees) : 
pre/post-processeur ou Machine virtuelle etendue 

des composants visuels specialises dans la 
navigation et 1 ' exploration des etats de la base (non- 
representes ) . 




L' invention peut §tre impl6ment6e de plusieurs 
manieres selon le contexte dans lequel elle est int6gr#e a 
une application, 

5 La figure 3 presente une architecture qui 

autorise trois niveaux d ' integration de la tragabilitS, de 
bas en haut : 

Les applications existantes peuvent continuer a 
acceder a la base de donnees (dite « principale ») de la 

10 meme maniere. La base peut soit garder sa structure 
d'origine et rediriger les acces a un journal associ^ (dit 
base interne), soit evoluer vers une organisation physique 
de type journal et offrir des vues ou un driver ayant en 
charge la translation des requetes et des resultats. 

15 Les applications existantes pourront §tre tres 

facileiaent munies d'un « curseur » h, condition que I'accds 
aux donnSes soit centralise (ce qui est gen^ralement le 
casr par exemple a travers un driver unique). Dans ce .cas.> 
1' application pourra offrir des moyens d' acces automatiques 

20 aux donnees de la base ( implSment^e d^sormais sous la forme 
d'un journal) et permettre aux utilisateurs d'actionner un 
curseur qui positionnera les lectures sur le repere 
6v6nementiel d6sir6. Des l^gferes adaptations pourront avoir 
lieu afin d'accorder la granulcirit6 des 6v6nements avec la 

25 s6inantique de 1' application. 

Les nouvelles applications, entierement 
construites sur la base des technologies d' inoculation de 
ggnSration de traces b^nef icieront implicitement du niveau 
le plus avanc6 de tragabilitS offert par ce proc§d6 

30 comprenant le suivi exhaustif de 1' Evolution des donnSes et 
de leur structure. Pour que le suivi de 1' Evolution des 
applications soit assurg au meme niveau, il suffira de 
recourir ^ des techniques declaratives de representation 
des sources, de les confier au meme journal et de les faire 




manipuler par un outil d ' assemblage muni lui-meme d'un 
module de tragabilite selon ce meme proc6d6. 

Cette architecture permet d'atteindre 
graduellement des niveaux de tragabilite des donnges 
5 persistantes de plus en plus elevees : 

« initial : representation et persistance 
(indispensable, prdalable), assure par le systdme initial 
de persistance 

journalisation des 6venements (utile, reprise sur 
10 panne ^ court terme, mais pose un probleme de 
reconstitution rapide des 6tats passes) 

historisation et versionnement (utile, car les 
valeurs stock^es sont multiples et peuvent comporter des 
variantes mais cette f onctionnalit^ gSnSre des problfemes de 
15 reconstitution en mode compatible avec le mode initial) 

<=» Evolution structurelle : le suivi des Evolutions 
des donnSes et du schema de la base de donn6es principale, 
compatible avec le mode initial 

d^pendance causale : la detection des flux de 
20 dSpendance dynamique et des liens de causality entre les 
donn^es de la base de donnees d' historisation ( journalis^e) 

Le spectre des applications de 1' invention 
couvre la plupart des cas ou il est utile de suivre 

25 1' evolution des donnees persistantes, des applications de 
gestion et jusqu'aux systemes de gestion de fichiers, en 
passant par des outils de conception reposant sur des 
referentiels (ou repository), ou au-dela des besoins de 
persistance, pour peu que le suivi de 1 'Evolution est 

30 utile. 

L' invention est decrite dans ce qui precede a 
titre d'exemple. II est entendu que I'homme du metier est a 




meme de rSaliser differentes variantes de 1' invention sans 
pour autant sortir du cadre du brevet • 



Id U&|JUL 



REVEMD IC ATI ONS 

1. Procede d' organisa-bion d'une base de donnees 
numeriques sous une forme tragable, comportant des etapes 
5 de modification d'une base de donnees numeriques principale 
par ajout ou suppression ou modification d'un 
enregistrement de la base principale et des Stapes de 
lecture de la base de donnees principale, 
caracteris§ en ce que 
10 I'^tape de modification de la base de donnSes 

principale comprend une operation de creation d'au moins un 
enregistrement ntimSrique comportant au moins : 

les identifiants numeriques uniques des 
enregistrements et des attributs concerngs de la base de 
15 donnees principale, 

un identifiant num^rique unique de I'^tat de la 
base de donnees principale correspondant h ladite 
modification de la base de donnees principale, 

les valeurs Slementaires des attributs qui leur 
20 sont affect^es a travers les operations 6 lament aire s , sans 
proceder au stockage des attributs ou des enregistrements 
non modifies, 

et d' ajout dudit enregistrement dans une base 
d'historisation interne compos4e d'au moins une table, 
25 et en ce que l'6tape de lecture portant sur 

tout Stat final ou antSrieur de la base de donnees 
principale consiste & effectuer une requete originelle 
associSe a 1' identif icateur unique de I'etat vise, a 
proceder a une transformation de ladite requete originelle 
30 pour construire une requete modifiSe d'adressage de la base 
d'historisation comprenant les criteres de la requete 
originelle et 1 ' identif icateur de I'etat vis6, et de 
reconstruction du ou des enregistrements correspondant aux 
criteres de la requete originelle et a I'etat visS, ladite 



gtape de reconstitution consistant a retrouver les valeurs 
61§mentaires ^ contenues dans les enregistrements de la base 
d'historisation, correspondant aux crit.eres de la requete 
originelle [afin de reduire les besoins de capacite de 
5 stockage et les -temps de traitement ] . 

2. Precede d' organisation d'une base de donnees 
numerique sous une forme tradable selon la revendication Ir 
caractSrise en ce que lesdits enregistrements de la base de 

10 donnees d ' histor isation contiennent ^galement des 
references a d'autres enregistrements de la base de donnees 
interne^ dans le but de preciser les liens de dependance 
dynamique de type source-destination constituant le flux 
causal des interferences entre les versions des donnees 

15 

3. Proc6de d' organisation d'une base de donnees 
numerique sous une forme tradable selon I'une quelconque 
des revendications precedentes, caract^risS en ce que 

ladite operation de modification de la base 
20 principale est une operation logique et que 

ladite operation d'ajout dans la base de . 
donnees d' his tor is at ion consiste a ajouter : 

un enregistrement identifiant I'etat de la base 
correspondant a 1' operation logique, 
25 autant d' enregistrements que de paramfetres de 

1' operation logique, 

un enregistrement pour le r^sultat 6ventuel de 
1' operation logique 

et a preciser par un lien de parents les 
30 regroupements d' operations depuis le niveau 616mentaire de 
modification jusqu'au niveau de la transaction, en passant 
le nombre de niveaux sgmantiques n§cessaires pour les 
applications . 




4. Proc6de d' organisation d'une base de donates 
numerique sous une forme tradable selon I'une quelconque 
des revendications pr6cedent.es ^ caract6ris6 en ce que la 
base de donnSes principale contient une ou plusieurs 
table{s), organisant les liens d' Evolution entre les 
identif iants des Stats successifs et alternatifs de la base 
principale, destin§e(s) k organiser les enregistrements de 
la base de donn6es interne, 

5. Precede d' organisation d'une base de donnSes 
n\am6rique sous une forme tragable selon la revendication A, 
caracterisS en ce que ladite ou lesdites tables des liens 
d' evolution entre les 6tats de la base principale 
contiennent des enregistrements specifiant les regies de 
correspondance entre les enregistrements de la base de 
donn^es interne d'historisation et les Stats de la base de 
donnSes principale. 

6. ProcSde d' organisation d'une base de donnSes 
numSrique sous une forme tragable selon I'une des 
revendications 4 a 5, caractSrisS en ce que ladite 
operation de lecture consiste a determiner ledit Stat de la 
base de donnees principale en se referant aux dits 
identif iants et aux tables des liens d' Evolution entre les 
etats de la base principale. 

7 . Architecture de gestion de base de donnees 
utilisant le procSdS d ' interrogation de I'une quelconque 
des revendications prScedentes, caracterisee en ce qu'une 
application interrogeant la base de donnees principale peut 
specifier I'Stat de la base de donnSes principale dSsire. 

8. Architecture de gestion de base de donnees 
selon la revendication 7, caractSrisee en ce que ladite 
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application peut operer des modifications sur tout etat de 
la base principals et donnant lieu, dans le cas de la 
tentative de modification d'un 6tat anterieur, a la 
creation de nouvelles alternatives d' evolution de la base 
5 de donnees principals dont les donn^es seront generSes par 
la meme base d'historisation interne. 

9. Proc^de d' organisation d'une base de donnees 
num^rique sous une forme tragable selon I'une quelconque 

10 des revendications 3^6, caract^rise en ce que les liens 
de dependances servent de criteres de remise en cause 
desdites operations dej^ effectu6es. 

10. Proc6d6 d' organisation d'une base de 
15 donnees numerique sous une forme tragable selon I'une 

quelconque des revendications 3 a 6, caract6ris6 en ce que 
les mises h jour effectuees sur des branches diff6rentes 
pourront @tre int^grees ou fusionnges dans le cadre d'un 
nouvel etat « heritant » desdites branches . 

20 

11. Precede d' organisation d'une base de 
donnees numerique sous une forme tragable selon I'une 
quelconque des revendications 3 a 6^ caracterise en ce que 
les cas d' evolution de structure des donnees de la base de 

25 donnees principale sont traites comme des cas particuliers 
d' evolution des donnees de ladite base, pour peu que la 
structure/schema de ladite base principale soit decrite de 
la fagon mentionnee pour les donnees, en tant que 
dictionnaire . 



12. Procede d' organisation d'une base de 
donnees numerique sous une forme tragable selon I'une 
quelconque des revendications 3 a 6, caracterise en ce que 
la base de donnees d ' historisation est exploree et 




interrog6e par des applications a travers le mode natif du 
SGBD afin d'obtenir des informations comma par exemple 
toutes les valeurs historiques d'un attribut et toutes lea 
incidences (dynamiques) de toute mise a jour et de naviguer 
au long des versions et des flux de d^pendance dynamique et 
ceci de fagon classique, selon le langage d' interrogation 
en vigueur, exig6 par le SGBD. 
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